The 3GPP (3rd Generation Partnership Project) authentication infrastructure, including AuC (3GPP Authentication Centre), USIM (Universal Subscriber Identity Module) or ISIM (IMS Subscriber Identity Module), and 3GPP AKA (Authentication and Key Agreement) protocol run between them, is a very valuable asset of 3GPP operators. It has been recognised that this infrastructure could be leveraged to enable application functions in the network and on the user side to establish shared keys. Therefore, 3GPP defined GBA, which is able to distribute shared secrets to a UE (User Equipment) and an authentication proxy which takes the role of a NAF (Network Application Function) using AKA-based mechanisms.
In accordance with 3GPP TS 33.220 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture” Version 8.0.0, FIG. 1 of this application shows a simple reference model for bootstrapping keys in a NAF and UE with support from a network infrastructure component, a BSF (Bootstrapping Server Function) and an HSS (Home Subscriber System).
With reference to FIG. 2, a typical flow with current GAA (Generic Authentication Architecture)/GBA specifications could be as follows:
1. A user tries to access an application via the Ua interface between the UE and the NAF.    a) The UE could have included already bootstrapping information as generated following steps 2 to 4 below. Then the flow will continue in step 5 below.    b) Otherwise, if the NAF requires the use of shared keys obtained by means of the GBA, but the request from the UE does not include GBA-related parameters, the NAF replies with a bootstrapping initiation message.
2. The UE, as redirected by the NAF or as configured prior communication with a NAF over Ua interface, contacts the BSF over Ub interface between the UE and the BSF.
3. The BSF then contacts the HSS over interface/reference point Zh between the BSF and the HSS in order to be able to execute AKA authentication towards the UE over the Ub interface. The purpose of this user authentication is solely to generate shared secrets. The BSF generates a B-TID (Bootstrapping Transaction Identifier) that will identify the credential material generated.
4. This B-TID is propagated to the NAF via Ub and Ua interfaces/reference points through the UE.
5. The NAF contacts the BSF over interface/reference point Zn using the B-TID received from the UE.
6. The BSF replies back with the credential material for NAF consumption.
At this point, the NAF is able to use the distributed credentials. In case this material should be used for further end-user authentication the NAF would initiate e.g. http-digest procedure using the distributed shared secrets as defined in 3GPP TS 33.222 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Access to Network Application Function using HTTPS” Version 7.3.0. The credential can also be used for other purposes than authentication, e.g. integrity, confidentiality, key derivation.
The overall procedure is shown in more detail in FIG. 2 of this application. In Step 201, the UE sends an http request via the Ua interface to the NAF. The NAF returns an http response comprising a bootstrapping request in step 202. The UE then sends in step 203 an http request for bootstrapping service based on the user identity to the BSF. In step 204, the BSF performs a get user security settings (GUSS) with the HSS.
An http digest Authentication and Key Agreement is executed between the BSF and the UE. In step 205 the BSF may return a “401 unauthorized” message, indicating that no authorization is available for the digest, comprising RAND (Random Challenge in Authentication) and AUTN (Authentication token). Based on RAND and AUTN, the mobile equipment executes an Authentication and Key Agreement with a UICC application in the UE, which returns a response RES (Response in Authentication) to the UE.
In step 206 the UE sends an http request comprising the response RES to the BSF. The BSF generates, in step 207, a B-TID (Bootstrapping Transaction Identifier) that will identify the credential material generated. In both the UE and the BSF, keys Ks are obtained from concatenated Ck and Ik, and a key Ks_NAF for the NAF is generated (steps 208a and 208b).
TLS (Transport Layer Security) encryption begins in step 209 with a TLS handshake between the UE and the NAF. The UE then sends an application protocol https request to the NAF in step 210, indicating that 3GPP GBA is supported, and comprising the B-TID.
The NAF contacts the BSF over interface/reference point Zn using the B-TID received from the UE and the NAF name in an authentication request in step 211. The BSF replies back in step 212 with an authentication answer comprising the credential material for NAF consumption: Ks_NAF, Prof, Bootstrap time, key lifetime).
At this point, the NAF is able to use the distributed credentials. In case this material should be used for further end-user authentication the NAF may initiate e.g. http-digest procedure using the distributed shared secrets (steps 213 to 215) as defined in 3GPP TS 33.222 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Access to Network Application Function using HTTPS” Version 7.3.0. The credential can also be used for other purposes than authentication, e.g. integrity, confidentiality, key derivation.
Additionally, 3GPP is defining for 3GPP Release 8 an architecture and related mechanisms for GBA Push Services applicable to scenarios where the UE is not forced to contact a BSF to initiate bootstrapping. FIG. 3 shows the reference model for GBA Push according to 3GPP TS 33.223 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) Push Function” version 8.0.0. A UE is linked with a NAF via two interfaces, Upa and Ua. The NAF is connected to a BSF via a Zpn interface. The BSF can communicate with an HSS via interface Zh, and with an SLF (Subscriber Locator Function) via interface Dz.
A typical flow with GBA-Push could be as shown in FIG. 4. The NAF generates a request for the generation of key material (Ks_NAF as in GBA) and related info, GPI (GBA-Push-Info) (step 401) and sends the request to the BSF (step 402). The BSF initially processes the GPI request in step 403 and send an AV request based on the IMPI to the HSS in step 404. The HSS returns in step 405 an AV response comprising the AV and USS to the BSF. The BSF uses this information in step 406 for the generation of the NAF SA, and sends a GPI response to the NAF comprising the requested GBA-Push-Info.
NAF then pushes the GPI (which includes RAND and AUTN) to UE over a Push channel/interface, Upa, which may be e.g. SMS (Short Message Service) and MMS (Multimedia Messaging Service) (steps 408 and 409 of FIG. 4). Finally (step 410 of FIG. 4), the UE runs AKA and generates Ks_NAF (as in GBA). This results in the establishment of a shared SA (Security Association) between the NAF and the UE (Ks_NAF). When the GBA Push procedure is completed and the key material received over the Upa interface (e.g. SMS) is processed, the UE is ready to receive protected Push messages from the NAF over Ua reference point (e.g. http). After the SA establishment, the NAF can send protected Push-messages to the UE, as shown is step 411. If a return channel exists, and if provided by the application utilizing reference point Ua, the UE can also use the established SA to send protected response messages to the NAF.
3GPP TS 33.224 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) Push Layer” Version 0.1.0. defines the typical Use Cases for GBA Push Services including NAF initiated Key Refresh, Distribution of Keys, Tokens, Vouchers and Tickets. GBA Push is also envisioned for Device Management procedures, DRM (Digital Rights Management), SUPL (Secure User Plane Location), Broadcasting and even as a means for load balancing GBA procedures.
GBA Push as currently defined in 3GPP TS 33.223 requires that the NAF is aware of certain information before the related GBA Push mechanisms can be triggered. The information comprises:                UEid (IMPI (IP Multimedia Private Identity), IMSI (International Mobile Station Identity), IMPU (IP Multimedia Public Identity), MSISDN (Mobile Station Integrated Services Digital Network) to use in GBA Push request to BSF;        UE Transport Id used for GBA Push service delivery method to the UE, e.g. MSISDN to send SMS;        BSF address;        and, optionally, a UICC (Universal Integrated Circuit Card) Application to use for GBA Push service.        
The 3GPP TS 33.223 does not define how the NAF gathers this information, which causes a number of issues, limitations and uncertainties. For some Push services it is assumed that the NAF and the UE have a previous relation where e.g. a user is subscribed to a NAF service. The user may provide some of the required information at subscription/registration time. For example, a user subscribing to e.g. a NAF broadcasting service, will be able to provide its MSISDN as UE Transport ID to get an SMS or MMS as Push delivery method. Furthermore the User may be able to additionally indicate its mobile and/or IMS operator provider.
Making users type personal information during subscription/registration processes is usually not very well perceived and always implies a risk to lose the customer. Furthermore, in this case, a user will not be able to provide much more information than the one indicated above during the subscription/registration process.                It is not likely that the user will know about its IMPI/IMSI, i.e. private identities, used by the system. This means that only public identities would be available as UEid for GBA Push requests to BSF. For reasons of privacy, NAFs may be restricted from accessing private identities, anyway.        With public identities it will not be possible for the NAF to discover the BSF. Especially with MSISDN where no domain name is available and mapping to IMSI is not possible. The user provided mobile/IMS operator provider may be of assistance in order to identify the right domain to address the query, but that will not provide all the required information to the NAF to discover the BSF, especially if multiple BSF instances are deployed within the mobile/IMS operator domain.        It is not likely either that the User will be aware of which UICC application to use.        
Furthermore, GBA Push procedures may fail even if the NAF manages to obtain the right set of information, as it may not be authorized by the BSF for the execution of GBA-Push services for that user. It could also be the case that a particular user is not enabled for GBA-Push in the first place.